1_Set-UID_Mechanism

Case study to Set-UID program

Linux password are stored in /etc/shadow file which is writable by root but not only by normal user.

How can we manage the password change?
We opt for a fine-grained access control: Unix provides a privileged program passwd that can only modify the /etc/shadow file.

There are 2 types of privileged program:

  • daemons : program that runs as background process. To be a privileged daemon it has to be run as root.
  • Set-UID programs: program marked with a special bit that inform the OS that such program is a special one

Set-UID Approach VS Service Approach

From the performance prospective, the Set-UID approach may be better, since it does not require any running background process. However, Set-UID approach has a much broader attack surface than the service approach. As we will see, this is due to environment variables.
The main issue is that in the Set-UID approach the env vars cannot be trusted since everyone can manipulate the env vars.
On the other hand, since service is started by a privileged parent process or OS, it can trust the env vars since they come from a trusted entity.
Although, still exists some attack surface on service approach to.

"Power Suit" Idea

With the Set-UID bit, we can grant "superpower" to a given program. However, the behavior of such process are restricted so that it can perform only a well-defined and specific task.